workspaceThumbnail: Don't rely on allocation to compute scale

We currently compute the target scale from the allocated height,
which means that it only becomes available after thumbnails have
been allocated at least once at their expanded height.

As the minimap is initially hidden, this only happens after it is
expanded for the first time, which means the corresponding transition
is not animated.

In order to allow for a fix, compute the target height ourselves
to allow the scale computation to work independently from the
expand factor.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3331>
(cherry picked from commit 2694a64ebbff93dea6de2d0b19591b1f2281f885)

diff --git a/js/ui/workspaceThumbnail.js b/js/ui/workspaceThumbnail.js
index 1302414fbf16d5aae4c036d33b6bcc3a4b265ec5..4e490478befe7e02152815ecd245291add25b9e6 100644 (file)
--- a/js/ui/workspaceThumbnail.js
+++ b/js/ui/workspaceThumbnail.js
@@ -1267,11 +1267,18 @@ export const ThumbnailsBox = GObject.registerClass({
         // Compute the scale we'll need once everything is updated,
         // unless we are currently transitioning
         if (this._expandFraction === 1) {
+            const [, natWidth] = this.get_preferred_width(-1);
+            const [, natHeight] = this.get_preferred_height(natWidth);
             const totalSpacing = (nWorkspaces - 1) * spacing;
             const availableWidth = (box.get_width() - totalSpacing) / nWorkspaces;
+            const availableHeight =
+                Math.min(natHeight, portholeHeight * this.maxThumbnailScale) -
+                themeNode.get_vertical_padding() -
+                themeNode.get_border_width(St.Side.TOP) -
+                themeNode.get_border_width(St.Side.BOTTOM);
 
             const hScale = availableWidth / portholeWidth;
-            const vScale = box.get_height() / portholeHeight;
+            const vScale = availableHeight / portholeHeight;
             const newScale = Math.min(hScale, vScale);
 
             if (newScale !== this._targetScale) {